Increasingly individuals and enterprises are conducting affairs over the World-Wide Web (WWW) and the Internet. Enterprises often have backend databases that capture transactions with consumers. For example, an airline has a centralized database that permits consumers to reserve seats on flights of the airline. Because multiple servers may be used to provide high-response and high-availability to the consumers, an airline will likely provide many frontend servers that are capable of accessing the central database. One obvious situation that occurs is if two separate consumers attempt to book a same seat on a same flight. To prevent this from happening, the separate servers communicate with one another via a two-phase commit protocol. So, before the centralized server commits to reserving a seat for a particular consumer the other servers acknowledge the commit and that the seat is being reserved for the particular consumer. Other distributed locking techniques may also be used to ensure that requested seat is not reserved or confirmed more than once.
In the previous example, another situation can arise with a distributed approach to performing transactions against a centralized database. Here, the database can fail before the seat is actually updated as being taken within the database. To ensure that this situation will not deny the consumer the seat that the airline committed to providing the consumer, the transaction is performed as a durable transaction.
Durability guarantees that transactions that have been committed to a database will permanently survive even if the database should fail before the database is actually updated. This is done by flushing the transaction log for the operation from memory to physical storage before the commitment is acknowledged. So, in the example, the centralized database first writes the reservation operation of the consumer to storage and flushes it from memory before the consumer receives an acknowledgement indicating that the seat was reserved. Once the flushed operation is on physical storage, the consumer receives the acknowledgement. Now, even if the database fails the consumer is assured that the seat reserved is his/her seat because the reservation operation can be replayed from the physical storage if the database fails when the database is brought back online.
One obvious drawback with durability is that the more frequently memory is flushed to storage, the slower performance becomes for users of the database. Often some data and certain types of operations that use durability do not have to do so and may not even be wanted by an enterprise. However, there is no way to turn durability on and off as desired.
Additionally, many enterprises' directories are essentially databases that are distributed and use durability to ensure commits and reliability to distributed users of the enterprise.
Thus, what are needed are improved techniques for selective durability to directory databases.